feat: Optimized index lookup in DateTimeCategoryAxis using binary search #2467
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Added `_binarySearch` helper method.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR improve the speed to scroll and panning when is using
DateTimeCategoryAxisTicket
Changes
Was created the
_binarySearchhelper function that is used the binary search algorithm to find the index in labels when is calling theupdateXValuesBecause the
List.containsandList.indexOfuses linear search that is On, so in large datasets is really slow. The binary search is O(log n) a lot of faster, and only requires the data to be sorted, what isn't a problem because it's a DateTime axis so the data will always be sorted.Testing
To test you can create an example chart using
DateTimeCategoryAxis, and compare the chart generate with this code with the master branch.Screen.Recording.2025-11-19.at.14.22.23.mov
Screen.Recording.2025-11-19.at.14.29.37.mov
How I find this problem
Looking in CPU profiler in dev tools, I found that 80% of the time was spent using
List.containsandList.indexOfScreen.Recording.2025-11-19.at.15.17.08.mov